Improve explicit histogram contention performance - #8717

My goal is to have OpenTelemetry metrics equal or exceed performance of other metrics systems, in an apples-to-apples comparison.

In this PR, I address the poor performance of explicit histograms under contention, as embodied by this prometheus/client_java benchmark.

I have issues with this benchmark. The real performance characteristic is more nuanced than can be captured by recording to a single bound series. To get the complete picture, I extended MetricRecordBenchmark to add a prometheus=false|true parameter, allowing comparison against prometheus alongside the parameters we've deemed valuable.

But there's no denying it: otel java's current simple lock based approach (predictably) gets steamrolled by a lock free design under contention.

The problem with fixing this is that lock based approach performs maximally well without contention. I've been thinking / iterating on designs on and off for months and there is no change I've found or am aware of that improves contended performance without regressing uncontended performance. This has been a sticking point in the past. So the approach I've taken with this PR:

• Thoroughly explore the solution space and to minimize the uncontended regression while still achieving the desired contended performance. I've explored dozens and dozens of angles and believe this will be difficult to improve on. The implementation in this PR is a version of the lock free design in prometheus/client_java, with modifications to avoid the complexity of having a buffer and to also optionally record min and max.
• Couple the regression with an improvement to partially offset. Observed that looking up Context.current() when exemplars are disabled is unnecessary and represents a significant chunk of work (at least on a relative basis).
• Plan for an escape hatch. I recommend we proceed with this implementation and accept the regressed uncontended performance. If users report the uncontended regression is unacceptable for their workloads, we can add a lock-based-implementation opt-in via ExplicitBucketHistogramOptions. Not adding preemptively without demand.

So how do we compare to prometheus/client_java? There are a lot of params that make it a bit overwhelming to interpret the data. Many of the param combinations tell variations of the same overall story. I've compressed the story into one graph which I think is fair and understandable. Notes:

• Light lines are before (i.e. main), dark lines are after (i.e. the PR branch). Prometheus only has after series because it's not being modified.
• Dashed lines are uncontended (i.e. 1 thread), solid lines are contended (i.e. 4 threads).
• Orange lines are prometheus, purple lines are OpenTelemetry.
• Benchmark includes these changes, which includes prometheus, disables capturing min/max for apples-to-apples comparison, and extending cardinality param set from [1, 128] to [1, 4, 32, 128] (this makes it easier to see how performance generally falls out as a function of cardinality).
• All data is available here, but the graph only includes cases where temporality=cumulative, bound=true.

Below is a before and after of the unmodified MetricRecordBenchmark. This shows clearly shows the contended gains and uncontended regressions.

Takeaways from a performance standpoint:

• Huge breakthrough in contended explicit histogram performance, ranging from 27%-1268%, with larger gains with low cardinality. I believe larger cardinality changes the cache profile. I.e. L1 vs. L2.
• Regression in uncontended cases ranging from 9%-22%. Although a few are flatlined.
• With this change, OpenTelemetry catches up to (and actually exceeds but prometheus could easily adapt to match) prometheus for contended performance, while equaling it for uncontended performance. For the cardinality=1, bound=true case the prometheus benchmark focuses on, OpenTelemetry improves from 23.3->224.6 million ops/s.